home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / misc / Graphics / sun.rasterfile.doc < prev    next >
Encoding:
Text File  |  1993-07-15  |  3.0 KB  |  85 lines
  1.  
  2. >From: jwz@teak.berkeley.edu (Jamie Zawinski)
  3. Newsgroups: comp.graphics
  4. Subject: Re: Sun Raster files
  5.  
  6. Date: 15 Nov 89 18:56:25 GMT
  7. Sender: news@pasteur.Berkeley.EDU
  8. Lines: 81
  9.  
  10.  
  11.  
  12.  
  13.    ... the manpage for 
  14. rasterfile(5) doesn't say anything about the format of byte-encoded
  15. images, or about plane/scanline ordering in multi-plane images.
  16. Pretty cool, yes?  Anyway, I have the firmly held belief that this
  17. information shouldn't be as hard to come by as it was for me.  So
  18. in the interest of spreading the data far and wide, here is what I
  19. know about the sun rasterfile format.  
  20.  
  21. The first thing in the file is
  22.  
  23.     struct rasterfile {
  24.         int ras_magic;
  25.         int ras_width;
  26.         int ras_height;
  27.         int ras_depth;
  28.         int ras_length;
  29.         int ras_type;
  30.         int ras_maptype;
  31.         int ras_maplength;
  32.         };
  33. The ras_magic field always contains the following constant:
  34.  
  35.     #define RAS_MAGIC 0x59a66a95
  36.  
  37. The ras_length field is the length of the image data (which is the length
  38. of the file minus the length of the header and colormap).  Catch: this
  39. is sometimes zero instead, so you can't really depend on it.
  40.  
  41. The ras_type field is ras_old=0, ras_standard=1, ras_byte_encoded=2,
  42. or ras_experimental=FFFF.  There doesn't seem to be any difference 
  43. between OLD and STANDARD except that the ras_length field is always 0
  44. in OLD.
  45.  
  46. I didn't deal with cmaps, so from the man page: "The ras_maptype and
  47. ras_maplength fields contain the type and length in bytes of the
  48. colormap values, respectively.  If ras_maptype is not RMT_NONE and the
  49. ras_maplength is not 0, then the colormap values are the ras_maplength
  50. bytes immediately after the header.  These values are either
  51. uninterpreted bytes (usually with the ras_maptype set to RMT_RAW) or the
  52. equal length red, green and blue vectors, in that order (when the
  53. ras_maptype is RMT_EQUAL_RGB).  In the latter case, the ras_maplength
  54. must be three times the size in bytes of any one of the vectors."
  55.  
  56. Regardless of width, the stored scanlines are rounded up to multiples
  57. of 16 bits.
  58.  
  59. I found the following description of byte-length encoding in Sun-Spots
  60. Digest, Volume 6, Issue 84:
  61.  
  62. > From:    jpm%green@lanl.gov (Pat McGee)
  63. > Subject: Re: Format for byte encoded rasterfiles (1)
  64. > 
  65. > The format is composed of many sequences of variable length records.
  66. > Each record may be 1, 2, or 3 bytes long.
  67. > 
  68. >  o  If the first byte is not 0x80, the record is one byte long, and 
  69. >     contains a pixel value.  Output 1 pixel of that value.
  70. >  o  If the first byte is 0x80 and the second byte is zero, the record
  71. >     is two bytes long.  Output 1 pixel with value 0x80.
  72. >  o  If the first byte is 0x80, and the second byte is not zero, the 
  73. >     record is three bytes long.  The second byte is a count and the 
  74. >     third byte is a value.  Output (count+1) pixels of that value.
  75. > 
  76. > A run is not terminated at the end of a scan line.  So, if there are 
  77. > three lines of red in a picture 100 pixels wide, the first run will 
  78. > be 0x80 0xff 0x<red>, and the second will be 0x80 0x2b 0x<red>.
  79. > 
  80. >     Pat McGee, jpm@lanl.gov
  81.  
  82.     -- Jamie Zawinski, jwz@teak.berkeley.edu
  83.  
  84.  
  85.